USB Descriptor Data
USB provides an expandable, hot-pluggable Plug and Play serial interface that ensures a standard, low-cost connection for peripheral devices such as storage devices, keyboards, joysticks, printers, scanners, modems, and digital cameras.
USB uses a set of data called “descriptors” to allow devices to be properly recognized by the host. In USB 1.x, the following five descriptors were used: ‘Device descriptor,’ ‘Configuration Descriptor,’ ‘Interface Descriptor,’ ‘Endpoint Descriptor,’ and ‘String Descriptor.’
The first four of these descriptors may be arranged hierarchically as illustrated in FIG. 1A. According to the “Renesas” website (http://www2.renesas.com):
(A) the Device Descriptor “specifies information such as the supported USB version, the Device Class, Device SubClass, Protocol, and maximum packet size for Endpoint 0. The Device Descriptor includes “Vender ID, Product ID, Device version, number of possible configurations, and Index of String Descriptor.” There is exactly one device ID per device.
(B) the Configuration Descriptor “specifies information such as the number of interfaces, and the value for selecting the configuration.” The Configure Descriptor includes: “Device attributes (i.e. how the device is powered), Consumption Electricity, and Index of String Descriptor.” There are one or more configuration descriptors per device. As shown in FIG. 1A, each configuration descriptor has one or more interface descriptors.
(C) the Interface Descriptor “specifies information such as the value for selecting the interface.” As shown in FIG. 1B, the Interface Descriptor is a ‘struct’ that includes: “Number of alternative settings, Number of endpoints, Interface Class, Interface SubClass, Interface Protocol, String Descriptor Index.”
(D) the Endpoint Descriptor “Specifies information such as the value for selecting the endpoint.” The Endpoint Descriptor includes “Transfer type (direction of transfer), Maximum packet size available for transfer, and Interval for transfers.” The Endpoint Descriptor “Exists independently for each Interface Descriptor. Depending on the interface, there may be an Interface Descriptor without Endpoint Descriptors, since Endpoint 0 is defined by a Device Descriptor and not an Endpoint Descriptor.”
Sometimes, in the literature, people use the term ‘Device Descriptor’ to refer to additional hierarchies of USB descriptor data, below the ‘Device Descriptor’ level. In the present disclosure, USB ‘Device Descriptor’ data specifically refers to data of the USB ‘Device Descriptor’ hierarchy.
Plug and Play Apparatus and Techniques
Plug-and-play techniques and apparatus have been ubiquitous in the computing world for well over a decade. Operating systems that provide plug and play functionality include but are not limited to Windows® (i.e. various ‘flavors’ including but not limited to Windows 98, Windows CE, Windows 2000, Windows XP, Windows Vista and Windows 7), MacOS® and many distributions of Linux.
FIGS. 2A-2B respectively are a block diagram and a flow chart describing a system including a printer coupled to a host device and a method of operating the host device and printer. In response to a device coupling between printer 20 (having port 22) and host device 100 (for example, a laptop, desktop or any other ‘PC’ device), printer 20 sends USB Device Descriptor data to host device 100 via respective USB ports (i.e. host-side ‘port’ 22 which may be a ‘male’ USB connector and device-side ‘port’ 110 which may be a ‘female’ USB socket) (see step S21).
A piece of operating system code running on host device 100 known as the USB host controller (illustrated in FIG. 1A as ‘USB host controller code 134’ which resides in memory 120 and is executed by processor((s)) listens to host-side port 110 and receives the USB device descriptor. The USB hub driver (i.e. implemented as executing code) generates directly or indirectly (e.g. by invoking a function call of one or more other code module(s)) a so-called ‘Hardware ID’ from at least a portion of the data of the USB Device Descriptor.
This ‘hardware ID’ specific for the peripheral device (in FIG. 2A, specific for the printer) is: (i) generated according to content of the USB Device Descriptor and (ii) forwarded (see step S23 of FIG. 2B) from the executing USB host controller 134 code to another piece of executing operating system code known as the plug and play manager 144. Plug and play manager 144 responds to receiving the peripheral device identifier (in this case, a printer identifier) by loading device driver(s) 26 selected from a ‘repository’ or ‘library’ of device drivers that matches the hardware identifier (in this case, a printer identifier) (see step S25 of FIG. 2B).
In FIG. 2A, this repository is referred to as the ‘OS Device Driver Database 142’ which (i) is located on the ‘host-side’ of the communications link 190 between respective USB ports 22, 11, (ii) may reside in any combination of device(s) on the host side including host device 100 and/or any other device; (iii) may reside in any combination of volatile 120 and/or non-volatile 122 storage; and which (iv) typically includes some sort of indexing data structure(s) which maps between various hardware IDs and the actual data driver data object(s) (e.g. files or any other data object). The ‘OS Device Driver Database 142’ and/or any portion thereof may be provided as a single data structure and/or may be distributed among data structures. In one non-limiting example, portions of the entirety of the ‘OS Device Driver Database 142’ may be located in the OS ‘Registry.’
Specifying of a Device Driver
The driver loaded in step S25 is not a generic driver determined exclusively by and/or primarily by a USB device class (e.g. a generic printer driver, a generic modem driver). Instead, a ‘customer’ device driver (i.e. as opposed to a ‘generic’ or ‘standard’ device driver for that device class—e.g. ‘standard printer driver,’ etc) that is ‘specific for’ the particular ‘hardware ID’ and that is ‘specific for’ the USB device descriptor data passed from the peripheral in step S23 is loaded in step S25.
There is a casual relation between (i) the content of the USB Device Descriptor passed in step S21 from the peripheral to the host which determines the Hardware ID (as well as the content of the hardware ID passed from the USB hub driver to the plug-and-play manager in step S23); and (ii) the identity of the actual device driver loaded into memory 120 in step S25. Even though the USB Device Descriptor as well as the Hardware ID do not exclusively determine the identity of the actual device driver loaded into memory 120 in step S25 (this is determined in conjunction with the content of at least a portion of the host-side-residing OS device driver database 142), the USB Device Descriptor as well as the Hardware ID certainly play a central role in determining the identity of the actual device driver.
Thus, in the present disclosure, it may be said that because the USB Device Descriptor as well as the Hardware ID play this central role in determining the identity of the actual device driver, that each ‘specify’ the device-specific driver loaded for the peripheral device (in FIG. 2A, this device is a printer 20—in FIG. 2B, this driver is loaded in step S25).
Steps S27 and S29 of FIG. 2B
The printer device driver(s) 26 loaded in step S25 exposes a printer API that translates device-independent printer commands (e.g. “EndPage”, or “PrintWindow”) to the specific printer's language. In addition, the printer API may also provide support for commands that are understood by a specific printer but are not necessarily device-independent printer commands, through API call such as “WritePrinter.” In this sense printer device driver(s) 26 may ‘expand’ or ‘extend’ the generic device-independent printer API to include additional printer commands
The printer API provided by printer device driver(s) 26 is available to user applications 24 (for example, word processor applications and Internet browsers or any other application) which utilize the printer API to send (see step S27 of FIG. 1B) specific printer commands (abbreviated as PCs) to the printer. The printer 20 receives these printer commands and sends (see step S29 of FIG. 1B) printer responses (i.e. ‘on line’ or ‘out of toner’) (abbreviated as PRs) to the user application 24.
FIG. 2C-2D describe a parallel case where the instead of coupling a printer device, a mass storage device 30 (having port 32) is coupled to host device. Thus, steps S31-39 are parallel to step S21-29, storage device driver 36 is parallel to printer driver 36.
Coupling of Composite Devices to PC Hosts
FIGS. 2A-2D relate to the case where a single or ‘simple’ device is presented to the host 100 by the peripheral via host-side port 100.
In other example, the user may couple a ‘composite’ device to the host device 200. The USB spec defines a ‘composite device’ as “A device that has multiple interfaces controlled independently of each other.”
Using composite device, multiple functions are combined into a single device. For example, a ‘mouse and a webcam’ or a ‘printer and a scanner’ The example of FIGS. 3A-3B relate to the case of a ‘printer and a mass-storage device.’ In this example, multiple drivers are loaded for a USB peripheral single device—the ‘device descriptor’ passed from the composite device 40 to the host 100, and the ‘hardware ID’ passed from the USB hub driver 134 and the plug and play manager 144 play a role in determining which particular drivers (i.e. specific for each device of the multiple devices of the composite device) are loaded for the ‘composite device’ 40. For a composite USB hub, hub driver code 134 may include a ‘composite bus’ component. Thus, for the case of the ‘composite device,’ the USB device descriptor and the ‘hardware ID,’ each may be said to ‘specify device-specific drivers.’
FIGS. 3A-3B illustrate four possible ‘peripheral device profiles’/USB fingerprints of peripheral devices that may be coupled with a host device 100 via a USB port.100.
Although the details in the specific implementation of various steps may differ for the composite device case, at the level of description of FIGS. 3A-3B (see elements 40, 42; see steps S41, S43, S45, S47 and s49), in all examples the host device loads multiple device drivers. In all examples, the host can send commands to multiple ‘targets’ after loading the drivers—for example, in the example of FIG. 3B, the host can send mass storage device commands to (i) a ‘target’ interface descriptor associated with a mass storage device type and (ii) ‘target’ interface descriptor associated with a printer device type.
Cell Phone Commands
Mobile telephones are ubiquitous in 21st century life, and require no introduction. FIG. 4 is a block diagram of an exemplary cellular telephone device 300 including: a display screen 310, a keyboard 304 (for example, a numerical keypad including mechanical buttons or provided in the context of ‘touch-screen’ functionality), cellular communication circuitry 314, volatile and/or non-volatile memory 320, one or more processors 130, a device-side port 322 and an antenna 306.
Cellular communication circuitry 314 (i.e. including any combination of hardware and/or software for communicating with the cellular network according to a cellular network protocol) is configured to handle communication with the cellular network (e.g. including but not limited to Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Evolution-Data Optimized (EV-DO), Enhanced Data Rates for GSM Evolution (EDGE), 3GSM, Digital Enhanced Cordless Telecommunications (DECT), Digital AMPS (IS-136/TDMA), and Integrated Digital Enhanced Network (iDEN)). For example, cellular communication circuitry 314 may handle voice and/or data protocols and/or messaging protocols of the cellular network.
Although cellular communication circuitry is illustrated separately from CPU 130 and memory 320 this is not a requirement and in some embodiments one or more functions of the cellular network communication circuitry 314 is implemented by the processor 130 and memory 320. It is noted that ‘circuitry’ refers to any combination and software and is not limited to ‘pure hardware’ implementation.
According to the example of FIG. 4, the following items are stored within memory 320: data storage repository 328 for storing cell-phone-specific data cellular telephones (e.g. storing received SMS messages or for storing network identifier data for identifying the cellular phone's device identifier or subscriber number, a log of cellular network operations carried out by the phone device 300, or address book information), and data management code 324 for managing data access to the cellular-telephone-specific data.
It is appreciated that FIG. 4 is a block diagram, and that memory 320 may include different types of memory such as generic storage (e.g. flash memory formatted using a file system or as object-oriented storage) as well as other types of storage (e.g. a special cell-phone chip in which a cell phone device identifier is stored). Similarly, data storage repository 328 is only illustrated in general terms and may be distributed over various locations—e.g. there is no requirement for SMS data and address book data to be stored together, SMS data may be stored in more than one format or location, etc
Data management code 324 (i.e. when executed by processor(s) 130) regulates access to the cell-phone-specific data stored in cell-phone-specific data storage repository 328. For example, a set of commands or command sequences may be defined for accessing previously-received SMS messages or for accessing cellular log records (i.e. describing previous cellular network operations) or for accessing address book entries or for accessing a cell phone identifier.
FIG. 5A is a flow-chart of a routine for handling SMS by a cellular telephone according to the prior art. In step S11, an SMS is received into the cellular telephone from the cellular network according to any pre-defined protocol defined by the cellular network. In step S15, the cell phone device 300 responds by storing the SMS (Short Message Service) storage in the data storage repository 328. As noted earlier, after the SMS is stored in the data storage repository 328 the hardware and/or software of the cell phone 300 may define a particular scheme or protocol for retrieving the SMS—for example, by a host device 100 coupled with the cell phone device. By defining a set of operations for accessing this data, code 324 and/or any dedicated hardware may regular access to this type (i.e. cell phone identifier information) of cell phone-specific data.
FIG. 5B is a flow-chart of a routine for handling a cellular network request for cellular telephone identifier information (e.g. International Mobile Equipment Identity (IMEI), Electronic Serial Number (ESN), or Mobile Equipment IDentifier (MEID)). The identifier information may be a control number of control data object used by the cellular network for cell phone activation. In step S21, the cellular phone receives a request for the phone identifier from the cellular network, and in step S25 the phone 300 responds to the request by accessing and/or reading the data from memory 320. For example, the phone may have a special chip including non-modifiable data that is also part of memory 320. The phone may be ‘hardcorded’ or configured by software (e.g. by operating system software) to provide this identifier data only after a specific request by the network or by a coupled host 100 via port 322. By defining a set of operations for accessing this data, code 324 and/or any dedicated hardware may regular access to this type (i.e. cell phone identifier information) of cell phone-specific data.
FIG. 5C is a flow-chart of a routine for logging cellular operations by a cellular telephone that carries out operations to interact with the cellular network according to the prior art. In step S31, the cell phone 300 carries out a cellphone operation—for example, sending or receiving an SMS or sending or receiving a voice cell phone call. In step S35, the cell phone device 300 responds to the carrying out of the operation by logging the operation to a ‘cell phone log’ stored in data repository 328. The hardware and/or software of the cell phone 300 may define a particular scheme or protocol for retrieving, at a later time, data of the cellular operations log or cell phone log residing in the data storage repository 328. By defining a set of operations for accessing this data, code 324 and/or any dedicated hardware may regular access to this type (i.e. cell phone identifier information) of cell phone-specific data.
FIG. 5D is a flow chart of employing data of an address book for initiating a cellular voice phone call via a cellular network. An address book entry stored in data storage repository 328 whose access is regulated by cell phone 300 (e.g. by code 324 which may define a standard series of operations for accessing the data) is specified by a user. The address book entry includes, at a minimum, a telephone number of a ‘target’ mapped to additional textual information about the target. When the address book entry is specified, the cell phone 400 responds by initiating a voice cell-phone call and/or by sending an SMS from phone 300 via the cellular network. By defining a set of operations for accessing this data, code 324 and/or any dedicated hardware may regulate access to this type (i.e. cell phone identifier information) of cell phone-specific data.
Communicating with a Peripheral Telephone Device from a Host Device
It is common for cell-phone vendors to provide ‘phone suite’ software applications for communicating with a cell phone coupled to a host computer 100—for example, running a ‘plug-and-play’ operating system such as Mac OS® or Windows® XP or Windows Vista® or Windows 7®.
When the cell phone device 300 is coupled to the host 100 as a peripheral ‘slave’ device, it is possible for the user to, for example, copy data (e.g. SMS data or phone address books entries) to his/her laptop or desktop computer and/or to operate the phone using a keyboard or other user control of the ‘host device.’ (e.g. laptop or desktop computer).
Upon coupling of the cell phone to the host device via the USB port, cell phone sends a USB hardware ID to the host device as in steps S21, S31, and S41. However, there is no predefined USB device class for cell phones as is the case for other peripherals (i.e. printers, modems, etc). Thus, the USB hardware ID corresponds to devices other than cellular phone devices—in the present disclosure, these non-cellular phone devices are referred to as ‘surrogate devices.’
For the present disclosure, a ‘surrogate device’ is a device having a class or type that is different from a phone device class—exemplary surrogate devices include but are not limited to USB hubs, modems, printers, wireless devices and human interface devices (HID).
FIGS. 6A-6B describe a situation related to the case where mobile phone is coupled to a host device (e.g. a PC) executing software of ‘mobile phone suite’ software. The executing code of the phone suite application in memory 120 is labeled as 152 in FIG. 6A.
In step S101 of FIG. 6A, in response to a device coupling between the host 100 and the mobile phone 200 (for example, a wired or wireless USB coupling), the mobile phone 200, presents itself to the host as a surrogate device (or array of one or more surrogate devices) other than a phone by passing a “surrogate device identifier” describing an array of one or non-phone devices. This surrogate device identifier is received by host device 100 via host-side port 110 (for example, a USB port). In particular, this surrogate device identifier is received by ‘USB host controller’ 134 of the operating system.
In many examples, this surrogate device identifier describes a ‘composite’ device see the discussion above with respect to FIGS. 2-3).
As was seen for previous cases (see step S23 of FIG. 1A, step S33 of FIG. 1D, step S75 of FIG. 3B) in FIGS. 6A-6B USB Host Controller 134 automatically forwards (see step S105) any device identifier (i.e. either the simple identifier or the identifier associated with a composite surrogate device) received via host-side port 110 to plug-and-play-manager 144—thus, in the example of FIGS. 4A-4B, the surrogate device identifier is forwarded to plug-and-play-manager 144 (step S105).
In general, plug and play manager 144 then loads (in step s109) into memory 120 a set of one or more drivers that match the device identifier(s) it receiver from USB host controller 134. For the specific yet ubiquitous example where the surrogate device identifier refers to a composite device, one or more teachings of FIGS. 2-3 are employed in step S109 for example, to load/invoke multiple driver objects for a surrogate composite device.
In one example relating to step S109, if the user couples an audio device (class 01h) to the host 100 via host-side port 110, plug and play manager 144 loads appropriate audio device drivers into memory 120, and these audio device drivers execute in kernel mode. Thus, for the particular case of FIGS. 6A-6B, the plug-and-play manager 144, which is not ‘aware’ of the ‘true identity’ of mobile phone 200, loads into memory 120 the surrogate device driver(s) 140 for the one or more surrogate devices of the surrogate device array (for example, printer drivers or modem drivers or human interface device (HID) drivers or any other drivers)—this is S109 of FIG. 6A.
In FIG. 6B, the term ‘surrogate device driver(s) 140’ refers either to the device driver specified by the hardware ID passed from the phone 200 to the host or, for the case of phones that present themselves as composite devices, to the device driver ‘indirectly’ specified by a USB hardware ID.
Surrogate Device Driver(s) 140 does not provide a ‘phone command interface. Instead, surrogate device driver is configured to receive and handle commands that match its device type—if ‘surrogate device driver’ 140 is a ‘Wireless Communication Device’ driver (or includes a ‘Wireless Communication Device’ for the case where there are a plurality of surrogate devices that are part of a composite surrogate device), then the surrogate device API exposed by surrogate device driver 140 is a ‘Wireless Communication Device’ command interface (i.e. for handling ‘generic’ and/or proprietary printer commands). If ‘surrogate device driver’ 140 is a modem driver, then the surrogate device API exposed by surrogate device driver 140 is a modem command interface, if ‘surrogate device driver’ is a mass storage driver, then the surrogate device API exposed by surrogate device driver 140 is a mass storage drive interface, as so on.
For the case of a composite surrogate device, the statements of the preceding paragraph may be true for each surrogate driver(s) of each device type.
One real-life example from known mobile phones is illustrated in FIGS. 7A-7B. FIG. 7A illustrates a ‘tree description’ of visible on a host device (in this case, operating the Windows® operating system) that has connected to a single Nokia® N95 phone that presents itself as a composite device comprising more than one surrogate device; FIG. 7B illustrates a ‘tree description’ of visible on a host device (in this case, operating the Windows® operating system) that has connected to a single Sony Ericsson® K310 phone
In this case of the Nokia® phone (see FIG. 7A), when the phone device is coupled to the host device (i.e. where the phone device is a ‘peripheral device’), the phone device presents itself in step 301 as a composite device including a plurality of USB interface descriptor . . . . This surrogate composite device includes a number of USB interface descriptors—including (i) a ‘Nokia N95 8 GB Portable Device’ of the ‘Portable Device’ device interface descriptor; (ii) a ‘Nokia N95 Modem’ Interface descriptor; (iii) a Nokia N95 8 GB USB ports of the ‘port device type’) and (iv) six separate wireless communications device.
In this case of the Sony-Ericsson® phone (see FIG. 7B), when the phone device is coupled to the host device (i.e. where the phone device is a ‘peripheral device’), the phone device presents itself in step 301 as a composite device). This surrogate composite device includes a number of USB interface descriptors (i) two separate modem devices; and (ii) two separate port devices.
For the case of ‘composite surrogate devices’, multiple surrogate class drivers 140 are loaded in step S109 for the single mobile phone (see FIGS. 2-3). For the example of the Nokia® N95 and the Sony Ericsson® K310 phones, the drivers for the devices illustrated in FIGS. 7A-7B are loaded in step S109, and are collectively known as surrogate class drivers 140.
In some examples related to phones that present themselves as composite surrogate devices, having multiple devices of the same type (for example, more than one ‘modem’ as illustrated in FIG. 7B) may be useful to allow the host to communicate with the phone over similar multiple data channels.
In order for phone suite application 152 of FIG. 152 (i.e. which is a client of the surrogate device drivers 142) to communicate with phone 200, phone suite application 152 utilizes the device API provided by the surrogate device driver 140. Since phone suite application 152 is custom-made and hard-wired for a particular family of phones (in some implementations, a given manufacturer (e.g. Motorola) may market several families of phones—in this case, the user may be able to type in his/her particular model or may provide related information using some sort of PC-based menu interface), phone suite application 152 is able to issue surrogate device commands rather than phone command according to some sort of mapping.
In one example, many phones expand the MODEM protocol (which was originally used for AT-commands) to additional commands, which all start with the AT-commands. These commands may be used to a variety of operations on the mobile phone 200 including managing contacts, getting information on the phone, updating phone software, etc. For example. Nokia(s) has a proprietary protocol called F-BUS used with its S40 family of phones. The communication starts with the following AT command:
Host: AT&F
Phone: AT&F OK
Host: AT*nokiafbus
Phone: AT
. . . from this point, the communication is in the F-BUS binary language. The F-BUS protocol includes a command to switch back to AT-commands protocol.
The commands sent by phone suite application 152 (for example, AT commands or F-Bus commands or printer commands such as ‘line feed’ or ‘print test page’) are thus surrogate device commands—specific to a surrogate device such as a printer or a modem or any other surrogate device. They may specific either to a ‘generic version of a surrogate device’ or to a specific version of a surrogate device (analogous to device drivers that expand the basic command set for a particular device such as a modem or printer).
A Discussion of FIG. 8
FIG. 8 is a flow chart providing a highly simplified description of a host device executing ‘phone suite software’ communicating with a peripheral phone device according to the prior art.
In step S61, host receives a USB hardware identifier (e.g. corresponding to a non-phone surrogate device(s)) from the peripheral phone device. In step S65, the host 100 loads the device driver(s) (e.g. surrogate device drivers) specified by the USB hardware identifier received from the peripheral phone 300.
In step S69, the host (e.g. phone suite software 152) communicates with the peripheral phone device 300 using the phone-specific loaded device drivers.
Below is a list of various features of the ‘phone suite’ paradigm for communicating peripheral cell phone devices:                (i) typically, each phone is associated with a different set of drivers. The situation illustrated in FIGS. 7A-7B where phones from different vendors require different drivers of different USB classes is not the exception, but is common;        (ii) in order to communicate with a cell phone, it is required to load one and often a number of phone-specific drivers specific to the cell phone coupled to the host. After the drivers phone-specific are loaded, the host employs the phone-specific drivers to communicate with the cell phone;        (iii) different phones require different drivers and load different combinations of drivers, often having different USB classes.        (iv) Although PC phone suites from different vendors may support similar functionality (e.g. retrieve SMS, retrieve entries from the address book, add entry to the address book, etc), typically phones from different vendors implement these ‘data access operations’ differently, and employ different protocols for reading cell phone data from repository 328.            (v) PC phone suite software 152 is usually ‘hard-coded’ to support a set of phones sold by the phone vendor, and a prior includes data and/or code describing that phone vendor's “schemes” for accessing data in the storage repository 328.